Use raw format when setting Editable content #667
Conversation
|
It may be easier once we move inline elements into a single string with paths where they start and and. When it happens that there are block elements in this content, we could flatten the text content. I guess this is for a bit in the future though. |
| @@ -233,7 +233,7 @@ export default class Editable extends wp.element.Component { | |||
| } | |||
|
|
|||
| content = wp.element.renderToString( content ); | |||
| this.editor.setContent( content ); | |||
| this.editor.setContent( content, { format: 'raw' } ); | |||
There was a problem hiding this comment.
Can you explain what are the benefits of raw content? I think performance, but I don't expect this setContent to be run a lot of times.
I guess my concern is. Are we really "ok" to skip the TinyMCE validation? What if we decide to add some content filtering https://www.tinymce.com/docs/configure/content-filtering/#valid_elements I'd prefer if we let TinyMCE perform this task for our selves.
There was a problem hiding this comment.
Re performance: I don't have a scenario in mind where we would be setting a lot.
There was a problem hiding this comment.
Are we really "ok" to skip the TinyMCE validation?
Yes, I think we should be fine with this. We shouldn't allow invalid content to enter the editor state in the first place. In fact, thinking on this some more, I found an obvious issue on master:
- Insert Heading block with some content
- Insert Text block with some content
- Merge Text block into Heading block
- Switch to Text mode
- Observe serialized Heading block includes undesired
<p>tag
The current behavior is really only giving us the illusion that it's helping in the context of the visual editor. We shouldn't need to leverage TinyMCE to ensure that we cleanly merge two blocks.
There was a problem hiding this comment.
I can be convinced, but this adds a lot of things for us to do. Not only when merging but also when parsing. We should provide helpers maybe to do this filtering, because it can be a difficult task to do and we should leverage this in a unified way.
There was a problem hiding this comment.
What specific things are you thinking that this will leave for us to do? And in what ways does TinyMCE's sanitization help with this that doesn't just display nicely in the editor, but also fixes the underlying broken content?
There was a problem hiding this comment.
I think each time we use an Editable we'd want to provide valid_elements to say which tags, attributes etc... this Editable allows (We'll need good defaults). if we use TinyMCE's valid_elements setting for this, there's not much left for us to do.
But I can be convinced that the content should have already been sanitised in the block attributes and I'm thinking, we could offer a helper to do this sanitization outside of TinyMCE.
There was a problem hiding this comment.
Yeah, I can see how we might want some sort of element validation, but I don't think it'll be in the direction of...
- Try setting invalid HTML to Editable
- TinyMCE cleans it up
- TinyMCE passes back clean HTML to us
...but rather more like...
- Editor state is always valid
- User manages to enter invalid markup into Editable
- It's cleaned up when markup is converted back into an element before being updated in state (related, Try avoiding parse to get content of Editable #523)
aduth
force-pushed
the
update/set-content-raw
branch
from
3aa0b53 to
3fd5cb0
Compare
Related: #635
This is a continuation of #635, applying a commit that had been removed there to use raw formatting when setting content to the TinyMCE instance. It was removed due to the behavior of the Text -> Heading transform creating content with an invalid structure that had relied on TinyMCE's content sanitization.
For example, what would have previously been transformed as
<h2>foo<p>bar</p></h2>should now be correctly transformed as<h2>foobar</h2>.Implementation notes:
I don't like that I chose to call to
.props.childrenin assigning the heading content. In fact, I think if at all possible, we should avoid having block implementers work with or manipulate these element trees at all. I think this can be improved by structuring the Text block's content attribute as an array. I recall we'd explored this at one point but found it "easy" to treat the text content as a single element blob. I suspect this will be an tempting escape for many blocks, so we should consider how best to encourage meaningful data structures for blocks, because doing so will help facilitate manipulating those structures (such as in transforming or merging blocks).I'll plan to explore these ideas further in a subsequent pull request.
Testing instructions:
Verify that there are no regressions in merging a paragraph block into a heading block, including if the text block includes multiple paragraphs (should only merge the first of the paragraphs into the heading and preserve the rest).